腾讯大数据产品

TDBank

TDBank 统一数据接入入口，提供多样的数据接入方式，以及高效实时的分布式数据分发。各个 BG 数据上报到 TDBank, 数据开发同学通过 LZ 任务在 TDW 上新建很多的表，得到最终结果之后，将结果导出到结果库中。

TDW（腾讯分布式数据仓库)

腾讯的数据门户流程如下，各业务数据接入 TDW（腾讯分布式数据仓库），由于数据门户与 TDW 是打通的，数据开发人员只需进行简单的配置操作，即可以提供给产品经理/分师析使用平台。产品经理/分析师可灵活自定义提取条件来提取想要的数据，提取出来的数据亦可做为分析组在用户画像平台上做进一步多维度、多样化的分析。若需要例行化的数据报表来观察数据走向或趋势，可通过“黄金眼”报表引擎进行可视化自助配置，所见即所得，操作简单、图表控件丰富。

数据门户

罗盘 or 黄金眼之类的 bi 工具。提取分析可以提供自助的数据提取分析服务，用户可灵活配置提取条件，提出的数据结果可以用于再次提取或在用户画像上进行进一步的分析。用户画像可提供实时的数据分析功能，并提供了多样化的分析方法，如对比分析、交叉分析、下钻分析等，分析的结果同样可以生成用户包进行再次分析也可以做为提取分析的数据源进行再次提取。当提取分析或用户画像过程中需要将数据例行化或生成固化报表随时查看时，可使用黄金眼平台配置报表。

调度任务

  1. LZ 与 US 平台: 数仓同学跑定时、调度任务用的

数据仓库 Data Warehouse 简称 DW

三个功能：存储数据、处理数据和分析数据。

  1. 在存储数据阶段，数仓接收和存储来自不同数据源的数据，比如来自业务数据库的，来自线下调研的，来自与其他业务交换获得的数据。
  2. 在处理数据阶段，数仓将对获取得来的数据源进行加工处理，具体的加工处理方法就是本文的重点，将在以下文章会进行详细阐述。
  3. 在分析数据阶段，主要是访问并提取数仓数据，并进行一定程度的分析，可视化，和交付的过程。

表信息

  1. 字段信息
  2. 关联任务
  3. 血缘详情 ？？
  4. 分区信息 ？？

主题域（多维度？）

主题域的划分方式有多种：

  1. 按照业务过程划分：如电商网站会有商家域，库存域，广告域，用户域等；
  2. 按照需求方划分：如产品域，运营域，财务域等；
  3. 按功能/应用划分：如微信朋友圈，搜一搜，看一看等。

横向来说，一般我们会将数仓模型分为四层，分别是 ODS 接口层，DW 主题域层，DM 集市层以及 APP 应用层。

分层的好处是：

  1. 整体结构清晰，数据流向明了
  2. 可避免底层数据的变动，引起上层数据的改动过大
  3. 屏蔽了底层复杂的业务逻辑，数据口径统一
  4. 高内聚，低耦合

分层

我们将数仓模型分为四层，分别是 ODS 接口层，DW 主题域层，DM 集市层以及 APP 应用层。

  1. ODS 接入层：不对数据进行清洗，接入原始数据，本质上数仓是要尊重数据，保留历史记录的。数据接入后，可对数据进行适当的清洗和聚合，比如：小时表聚合成天表（离线数据，我司业务数据侧一般是 T+1 处理），或者按照更新时间，只保留当天最后一次的更新记录。

  2. DW 主题层：主题层保留了数据明细，只是对接入层的数据/事实进行轻量的聚合，并且在同一个主题域下关联其余的接入层表，形成该主题的明细表。比如接入层的用户主题下的数据分别是用户基础信息，用户消费数据，用户行为数据，那么在用户主题层，我们会利用用户的统一 id 做唯一关联，将用户基础信息+消费信息+行为信息关联成一张用户消费明细表，并做轻量的聚合。

    1. 这里可能还会有一些明细层

  3. DM 集市层：集市层保留了主体层的信息，并且可以跨主题进行主题之间的关联合并，得出的是一张跨主题合并的明细表，比如用户主题数据+设备主题数据=用户设备消费明细表，在这个过程中，还可以通过事实数据衍生出其他的派生数据，如根据用户每天的支付数据，衍生出用户近 N 日支付频次，再衍生出近 N 日消费的用户是高频还是低频，或者衍生出用户生命周期的所处阶段（用户新增，流失，留存，回流）。

有了各主题的大宽表，也有了跨主题的大宽表，我们可以通过对宽表的维度+指标聚合得到数据的分布，从不同的角度去看业务现状，将明细宽表做聚合汇总，可得到集市层的聚合汇总宽表（聚合舍弃明细的最小粒度：如用户消费明细：最小粒度为用户 id； 设备明细：最小粒度为设备 id；用户设备明细：最小粒度为用户 id+设备 id）.

  1. APP 应用层：对集市层的明细表或者聚合汇总表，进行再次的聚合汇总形成需要的报表，也就是我们常说的数据立方体。

一般来说，DM 集市层与 APP 应用层是属于数据门户的。

滴滴顺风车数仓架构

DIM 层： 维表层面：

  1. 公共维度层，基于维度建模理念思想，建立整个业务过程的一致性维度，降低数据计算口径和算法不统一风险；
  2. DIM 层数据来源于两部分：一部分是 Flink 程序实时处理 ODS 层数据得到，另外一部分是通过离线任务出仓得到；
  3. DIM 层维度数据主要使用 MySQL、Hbase、fusion(滴滴自研 KV 存储) 三种存储引擎，对于维表数据比较少的情况可以使用 MySQL，对于单条数据大小比较小，查询 QPS 比较高的情况，可以使用 fusion 存储，降低机器内存资源占用，对于数据量比较大，对维表数据变化不是特别敏感的场景，可以使用 HBase 存储。

改进的点 or 数据资产平台的作用

  1. 提升了数仓中数据的复用性
  2. 提高了数仓的规范性，指的是数仓的设计规范，模型规范，命名规范，开发规范和流程规范
  3. 提高数据质量
  4. 元数据管理： 技术元数据以及业务元数据的管理
  5. 数据安全： 数据权限把控，数据安全性（存储，使用，传输过程等）

SQL 语句

主要可以划分为以下 3 个类别。

  1. DDL（Data Definition Languages）语句：数据定义语言，这些语句定义了不同的数据段、数据库、表、列、索引等数据库对象的定义。常用的语句关键字主要包括 create、drop、alter 等。
  2. DML（Data Manipulation Language）语句：数据操纵语句，用于添加、删除、更新和查询数据库记录，并检查数据完整性，常用的语句关键字主要包括 insert、delete、udpate 和 select 等。(增添改查）
  3. DCL（Data Control Language）语句：数据控制语句，用于控制不同数据段直接的许可和访问级别的语句。这些语句定义了数据库、表、字段、用户的访问权限和安全级别。主要的语句关键字包括 grant、revoke 等。

DDL 语句是数据定义语言的缩写，简单来说，就是对数据库内部的对象进行创建、删除、修改的操作语言。它和 DML 语言的最大区别是 DML 只是对表内部数据的操作，而不涉及到表的定义、结构的修改，更不会涉及到其他对象。DDL 语句更多的被数据库管理员（DBA）所使用，一般的开发人员很少使用。

数据概念

  • 小计（合并）
  • 筛选： Filters
  • 维度：数据的属性
  • 指标：量化衡量的标准
  • 数据源：（一般指一个数据库 ？？？？）
  • CK clickHouse
  • PG: PostgreSQL ?
  • DB 表？
  • TDW
  • TDBank
  • US or LZ: 大计算量的操作，类似 maxCompute. 洛子任务调度是公司级别的统一调度平台，可以执行一些定时任务，例如：出库任务，定时执行脚本，定时计算
  • HDFS：分布式文件系统。
  • HBase： Apache HBase 是 Hadoop 数据库，一个分布式、可伸缩的大数据存储。 技术分层：
  1. 存储引擎： hadoop hdfs 之类的存储流水明细，数据经过清洗之后，一般会经过 clickHouse 之类的 ？？？这一步骤是通过提交任务式分析完成。页面实时分析秒级返回分析结果，提交任务式分析需要 5-15 分钟返回结果。
  2. 计算引擎 TDW：
    1. hadoop map reduce 经过计算 ？ 将明细和结果数据导出到 clickHouse
    2. spark 经过计算 ？ 将明细和结果数据导出到 clickHouse
  3. 调度任务任务：
    1. 洛子任务做大计算量处理
    2. 定时跑，有先后依赖跑任务等
    3. 将处理完的数据，同步到结果库中，提供给 DM 数据集市层。
  4. 数据应用：
    1. 经营指标
    2. 增长分析工具
    3. 指标异动监控
    4. ABTest

ClickHouse

ClickHouse 是一个用于联机分析(OLAP)的列式数据库管理系统(DBMS)。

我们首先理清一些基础概念：

OLTP：是传统的关系型数据库，主要操作增删改查，强调事务一致性，比如银行系统、电商系统。 OLAP：是仓库型数据库，主要是读取数据，做复杂数据分析，侧重技术决策支持，提供直观简单的结果。

列式数据库和行式数据库区别，在传统的行式数据库系统中(MySQL、Postgres 和 MS SQL Server)。通过 ClickHouse 实践，完美的解决了 MySQL 查询瓶颈，20 亿行以下数据量级查询，90% 都可以在 1s 内给到结果，随着数据量增加，ClickHouse 同样也支持集群。

Postgres

高并发读写很强。 查询比较快，稳定性很强。

大数据开发的流程

  1. http 上报数据到 tdbank。收入数据的流水，上报到计费中心。如何到 tdbank 的？tdbank 上创建一个业务，通过调用提供的 api， 返回一个 ip 和端口，直接 post 指定的接口即可。
  2. tdw 就是一个数据计算平台 ？？？ 现在都是在 idex 平台上进行开发测试的？ 管理脚本内容？
  3. idex 平台创建 pysql 脚本，idx 在线平台写 py, SQL 在测试库中写代码。上传至 US 调度平台 us 平台。idex 只管查询的平台， us 是只管调度的平台。
  4. us 上主要是新建任务、任务补录，任务之间的关联、先后关系。 洛子任务，只管调度，定时执行 py 脚本。 包含任务的新建、补录。 任务之前会存在一些关联关系，比如小周期依赖大周期，时间先后等。新建视图和任务，设置依赖关联类型等。任务之间可通过连线关联来设置父子任务的依赖关系，目前有 5 种周期类型：月、周、天、小时、分钟和 1 种“非周期”类型：
    1. 大周期依赖小周期
    2. 小周期依赖大周期
    3. 同周期依赖
    4. 周期（非周期）任务依赖非周期（周期）任务
    5. 自依赖
  5. us 平台，也就是以前的洛子平台上，数据仓库的同学，需要针对不同维度，开发 py 脚本，写一些定时任务、表的关联处理等操作将数据插入到 tdw 表中去。？？
  6. us 上还会有任务，将 tdw 表的数据，再次经过处理之后，出库到 pg, mysql 等结果库中，成为一张张的报表。这些报表，是会有权限的，在罗盘的报表平台上能够进行管理。
  7. 工作表：将报表或者结果库中的表？做成一张张的工作表，会做一些额外的处理，比如说加上一些计算字段，多表关联等，处理成一张最终所需的大表。
  8. 仪表盘：将工作表配成一张张仪表盘。 仪表盘可以直接拉出工作表的所有字段名，通过拖拽的形式，指定指标和维度，以及需要渲染的图形，再加上一些筛选条件之后。 筛选条件，会是动态拼接成 sql，（这种根据字段和条件来拼接 sql 的逻辑本来就有沉淀了，所以这也是为什么驾驶舱的 node 会这么进行处理） 做一个取数操作，当然这里是有权限的。配置的数据库（mysql）会保存图表的配置信息，数据从一些结果库筛选出来，或者调用结果库上层封装的数据底座的接口，做了一个渲染操作。这就是仪表盘。
  9. 推送：将仪表盘或者图表（？？？） 先用 ssr 做渲染了将内容直接存入 CKV （redis） 中，每天定时跑完 ssr 之后，发送邮件，或者推送企业微信。

数据中台

数据中台的目的是完成数据的采集、建设、管理、使用这四个环节，让数据从生产到使用过程变得丝般顺滑，不仅不让数据资产成为累赘，还会最大限度发挥出数据潜藏的价值。

剩下流转到我手上需要开发的需求，都是新增交互，或者之前抽象不足的组件。

设计一个通过拖拽，然后交换位置的组件，给思路就可以。？？？ 看你在带一个项目，你一般都是怎么协调资源的？？？？

数据

对于所有的业务来说，数据都是最重要的财富之一，数据分两种：

  1. 操作型数据：一般一次处理一个事务记录，通常不保留历史数据，只需要修改数据以反映最新的状态即可。
  2. 分析决策型数据：研究和分析业务的运转情况，通常需要保留历史数据以用于记录业务的变化状态，并可更精确地评估业务的健康度。
Last Updated:
Contributors: yiliang114